CI/CD：用 AI 配置和排查自动化部署
你会学到什么
前四节打通了初始化、版本控制、代码提交与质量防线。本节是全章的"统领"——前面让 AI 写的测试、做的构建、配的 lint，最终都在这一层汇成机器自动执行的流水线：代码 push 到 GitHub 后，CI 自动跑检查、构建，CD 自动部署上线。
核心内容：容器化与矩阵化两大支柱（含 Docker 本地实操与真实踩坑）、用提示词让 AI 生成 CI/CD 配置、Vue3 部署方案选型、AI CI/CD 工具生态。
CI 构建失败的排查和测试覆盖率配置，放在第13章（组件库测试）中结合测试实战一起讲——那里有具体的测试代码和失败场景可以分析。
CI/CD 的两个概念（30秒）
CI（Continuous Integration，持续集成）：push 后自动跑 lint + build + test，几分钟内发现问题。 CD（Continuous Delivery/Deployment，持续交付/部署）：构建通过后自动部署到线上。
"持续"体现在它是一条流水线——前面章节让 AI 写测试、做构建，最终都要交给机器固化成脚本自动执行。工具层面绕不开一个名字：Jenkins，开源界 CI/CD 的老大哥，后续很多 CI/CD 系统都基于它的思路发展而来，至今仍活跃在大量服务器上（生态丰富、有基金会维护）。本课程用 GitHub Actions——开源项目最容易接触到的现代方案。
没有 CI/CD → 每次手动构建、手动部署；本地跑一遍 build 觉得没问题就上线，结果同事 pull 下来发现挂了。 有 CI/CD → push 后3分钟自动通知"构建失败"，在合并到 main 之前就拦截了。
本节是前置概念章节：把容器化、矩阵化这些概念铺平并做本地实操，完整的线上 CI/CD 实操在课程后面的部署章节串起来。重点讲怎么用 AI 配置 CI/CD 和部署。
容器化开发与矩阵化 CI/CD
CI/CD 自动化有两个核心支柱：容器化解决环境一致性问题，矩阵化测试解决版本兼容性问题。
容器化不是唯一方案，先想清楚要不要用
很多人不愿意碰 Docker，是因为把它当成了部署的"必选项"——其实不是：
- 裸机直接部署：CI 流程里挂一个 SSH 插件，构建完成后用脚本把产物上传到服务器。替代了人手工上传的过程，单应用、个人应用完全够用
- 容器化部署：当应用复杂到网络、依赖环境、文件环境可能互相冲突时才必须上——用一个 Dockerfile 锁定构建环境，制作成镜像后任何装了 Docker 的机器（Linux/Windows/macOS，跨平台）都能运行
- K8s 服务编排：容器化的进阶形态，多容器、多服务的调度编排，本课程不展开
Docker 容器化：让环境一致
本地开发环境、CI 环境、生产环境经常不一致。你本地用 Node 24 跑得好好的，CI 用 Node 22 就挂了。Docker 用一个 Dockerfile 锁定运行环境——同一份镜像在任何地方都一样。（版本提醒：Node 20 已于 2026-04-30 停止维护，新项目基线用 Node 22/24。）
Vue3 项目的 Dockerfile 核心就是多阶段构建：第一阶段用 node:24-alpine 跑 install 和 build，第二阶段用 nginx:alpine 托管静态文件。最终镜像只有 nginx + 构建产物，体积从 1GB+ 降到约 20MB。
让 AI 生成三件套：
请为当前 Vue3 项目创建 Docker 配置：
1. 多阶段构建的 Dockerfile（node:24-alpine → nginx:alpine）
2. nginx 配置支持 Vue Router history 模式
3. .dockerignore 排除 node_modules、dist、.git、.env
text
AI 会生成类似下面这套可直接复制的内容（pnpm + SPA 的标准形态）：
# ---- 构建阶段 ----
FROM node:24-alpine AS build
WORKDIR /app
RUN corepack enable && pnpm config set registry https://registry.npmmirror.com
COPY package.json pnpm-lock.yaml pnpm-workspace.yaml ./
RUN pnpm install --frozen-lockfile
COPY . .
RUN pnpm build
# ---- 生产阶段 ----
FROM nginx:alpine
COPY --from=build /app/dist /usr/share/nginx/html
COPY nginx.conf /etc/nginx/conf.d/default.conf
EXPOSE 80
dockerfile
# nginx.conf：Vue Router history 模式的关键 fallback
server {
listen 80;
server_name _;
root /usr/share/nginx/html;
index index.html;
location / {
try_files $uri $uri/ /index.html;
}
}
nginx
# .dockerignore：这些文件不进构建上下文（它们本来也不该进版本库）
node_modules
dist
.git
.env
*.log
text
为什么要两个阶段：构建阶段负责下载依赖并产出 dist/，生产阶段只把 dist/ 拷进 nginx 镜像——TypeScript 类型声明、构建工具、commitlint、测试框架这些开发依赖全部留在第一阶段，最终镜像里一个字节都不带。EXPOSE 80 暴露的是容器内部端口：容器与宿主机网络是隔离的，想访问容器里的 nginx，必须用端口映射在"隔离层"上开一个洞，对准容器的 80 端口。
容器化的意义不仅是部署。本地开发时也可以用 Docker 统一团队环境，新同事 clone 下来直接 docker build 就能跑，不需要折腾本地 Node 版本。
实操：本地把镜像跑起来
本地需要一个运行中的 Docker 环境——Docker Desktop 或更轻量的 OrbStack 都可以，先把服务启动。然后让 AI 继续干：
尝试构建并运行，对外端口设置为 9090（避开 8080 这类常被占用的端口）
text
对应的底层命令值得认识一遍：
# 在 Dockerfile 所在目录执行；结尾的点号 = 构建上下文取当前目录，
# 默认读取当前目录下名为 Dockerfile 的文件（大小写必须一致）
docker build -t ai-chat-ui .
# 宿主机 9090 → 容器 80 的端口映射
docker run -d -p 9090:80 ai-chat-ui
# 查看本地镜像（OrbStack/Docker Desktop 也有 Images 面板）
docker images
bash
访问 http://localhost:9090 验证。构建时间偏长是正常的——第一次要拉基础镜像、装全部依赖。
实操踩坑：构建脚本批准与国内加速（真实记录）
实际演示中第一次构建就失败了，报错指向"构建脚本未被批准"。这不是玄学，是 pnpm 10+ 的安全策略：依赖包的安装期构建脚本（如 esbuild、sharp 的二进制下载）默认被拦截，需要显式批准。两种修法：
# 方式一：交互式批准（本地）
pnpm approve-builds
# 方式二：写进 pnpm-workspace.yaml 的 allowBuilds（Docker/CI 必须用这种，非交互）
# onlyBuiltDependencies:
# - esbuild
# - sharp
bash
Docker 场景的关键细节：pnpm-workspace.yaml（里面带着 allowBuilds 批准结果）必须在 pnpm install 之前 COPY 进镜像——只拷贝 package.json 和 lockfile 会导致 Docker 构建读不到你本机的批准记录。上面 Dockerfile 的 COPY 顺序已经处理了这一点。
第二个加速手段：构建慢时直接告诉 AI"使用国内加速源重新构建"，它会改用 npmmirror（淘宝源）等镜像下载依赖。整个演示经历了多轮调整——从报错、修复、换源到把冗长的 Dockerfile 精简——最后才跑通。
这带来一个重要认知：AI 并不能一次性把 CI/CD 全配好，和传统配置一样需要多轮迭代；区别在于每一轮的"看日志→定位→改配置"都由 AI 代劳，人只做判断。这也是很多前端同学过去不敢碰运维的本质原因——不是难，是每一轮试错的成本太高，而 AI 把这个成本打下来了。
GitHub Actions 矩阵化：提前发现兼容性问题
GitHub Actions 的 matrix 策略让同一套代码在多个环境下并行测试。一个真实案例：某 Electron 桌面应用的开源仓库，release 配置里用 matrix 同时构建 x64 和 ARM64 两种架构 × Windows/macOS/Linux 多个系统——只改配置文件，CI 就自动产出全部平台的安装包制品。
strategy:
matrix:
node-version: [22, 24] # 两条活跃 LTS 线同时验证
yaml
请修改 CI 配置，用 matrix 策略测试 Node.js 22 和 24 两个版本
text
矩阵化还可以扩展到多操作系统（ubuntu/macos/windows）。比起容器内的交叉编译，在原生环境并行构建更快也更省事。
这两个概念结合就是现代 CI/CD 的基础：Docker 确保环境一致，matrix 确保版本兼容。配置都可以让 AI 一句话生成。
用 AI 生成 CI/CD 配置
不需要手写 YAML，不需要记 Action 名称。告诉 AI 项目信息和要跑的步骤，AI 输出完整配置：
请为当前 Vue3 项目创建 GitHub Actions CI 配置：
1. 触发条件：push 到 main + 所有 PR
2. 运行环境：ubuntu，Node.js 22/24 矩阵，pnpm 12
3. 步骤：安装依赖 → lint → build → test
4. 使用 --frozen-lockfile 确保依赖版本一致
text
产出的标准形态长这样（可直接复制为 .github/workflows/ci.yml）：
name: CI
on:
push:
branches: [main]
pull_request:
jobs:
ci:
runs-on: ubuntu-latest
strategy:
matrix:
node-version: [22, 24]
steps:
- uses: actions/checkout@v4
- uses: pnpm/action-setup@v4 # 按 packageManager 字段装 pnpm
- uses: actions/setup-node@v4
with:
node-version: ${{ matrix.node-version }}
cache: pnpm # 自动缓存 pnpm store，提速明显
- run: pnpm install --frozen-lockfile
- run: pnpm lint
- run: pnpm build
- run: pnpm test
yaml
--frozen-lockfile 是关键参数：严格按 lockfile 安装依赖，lockfile 和 package.json 不一致时直接报错而不是静默更新——防止"本地没问题 CI 挂了"。顺带一提，pnpm 检测到 CI 环境时默认就启用 frozen-lockfile，显式写出来是为了可读和保险。两个 setup Action 的顺序也有讲究：pnpm/action-setup 必须在 actions/setup-node 之前，否则 cache: pnpm 找不到 pnpm 可执行文件会直接失败。
CI 构建失败了怎么办
本地好好的 push 上去挂了——这是最常见的 CI 问题。传统方式在几百行日志里找报错，AI 时代两种做法：
# 做法一：手动两步
# 1. 获取失败日志
gh run view <run-id> --log-failed
# 2. 把日志喂给 AI
> CI 构建失败了，日志如下：
> [粘贴日志]
> 请分析失败原因并给出修复步骤。
# 做法二（更省事）：把 GitHub token 给 AI，让它自己读日志、自己修
> 这是我的 GitHub token（在 .env 中），读取最近一次 CI 失败的日志，
> 分析原因并直接修复提交
text
做法二复用了第2节团队实战的凭据配置——AI 拿着 token 调 GitHub API 拉取失败日志，定位问题、改代码、提交、推送，全程不再需要你中转日志。
常见原因 AI 秒定位：lockfile 没提交、TypeScript strict 模式、Node 版本不一致、pnpm 构建脚本未批准（上一节的 ERR_PNPM_IGNORED_BUILDS）、测试超时等。
详细的测试 CI 排查（覆盖率门禁、测试快照不匹配、jsdom 缺 API 等）在第13章03节结合测试实战讲解。
Vue3 部署实战
CI 跑通后，下一步是自动部署。三种方案按场景选择：
部署方案一览
| 方案 | 配置难度 | 适用场景 | 费用（2026-10 核实） |
|---|---|---|---|
| Vercel | 最低（零配置） | SPA、SSR、文档站 | Hobby 免费版：不限部署次数、每月 100GB 带宽；国内访问慢 |
| GitHub Pages | 低（一条提示词） | 文档站、静态站 | 免费 |
| EdgeOne Pages（腾讯云） | 低 | 国内访问优先的静态站 | 个人版免费（额度以 pages.edgeone.ai 定价页为准） |
| Docker + 自有服务器 | 中（AI 生成） | 公司内部、客户私有部署 | 服务器成本 |
| Netlify | 低 | 静态站、SPA | 免费额度充足 |
| Cloudflare Pages | 低 | 全球加速 | 免费版无带宽硬上限（500 次构建/月，2026-11-07 核实） |
选型一句话：海外项目/开源作品选 Vercel；面向国内用户选 EdgeOne Pages（Vercel 在大陆访问慢甚至 SSL 握手失败，EdgeOne 用国内边缘节点加速）；私有部署选 Docker + 自有服务器。另外注意这些平台的商业玩法：初期给免费额度，等你的流量和请求频次上来了再收费——和国内云平台"先让你用、用量上来再付费"是同一个套路，把项目托进去之前先看清超额单价。
方案一：Vercel（最简单）
Vue3 SPA 用 Vercel 部署最简单：
方式一（推荐）：GitHub 集成
1. 在 vercel.com 导入 GitHub 仓库
2. Framework Preset 选 Vue.js
3. 点击 Deploy
之后每次 push 到 main 自动重新部署。零配置。
text
方式二：让 AI 配置自动部署
请在 CI 配置中添加部署步骤：
- 只在 push 到 main 时部署
- 用 Vercel CLI 部署
- Vercel Token 存在 GitHub Secrets 中
text
方案二：GitHub Pages（免费）
组件库文档站（VitePress）适合用 GitHub Pages：
请为项目配置 GitHub Pages 自动部署：
1. 在 ci.yml 基础上添加 deploy job
2. 只在 push 到 main 时触发
3. 依赖 ci job 通过后才执行
4. 用 pnpm docs:build 构建文档
5. 用 actions/deploy-pages@v4 部署
text
部署完成后访问 https://<username>.github.io/<repo>/。
方案三：Docker + 自有服务器
公司内部项目、客户私有部署需要自己管理服务器。Dockerfile/nginx.conf/.dockerignore 三件套在本节"容器化"部分已经给全（node:24-alpine → nginx:alpine），本地验证通过后：
docker build -t my-vue-app .
docker run -d -p 9090:80 my-vue-app
# 本地验证 http://localhost:9090 通过后，镜像推送服务器运行
bash
多阶段构建的最终镜像只有 nginx + 静态文件，体积从 1GB+ 降到 20MB；Docker 跨平台，同一个镜像可以传到任意 Linux 服务器上运行。
部署常见问题排查
部署后白屏是最常见的问题：
> Vue3 项目部署到 Vercel 后页面白屏。
> 本地 `pnpm build && pnpm preview` 正常。
> Vercel 构建日志没有报错。
> 请帮我排查可能的原因。
text
AI 通常会检查三个方向：publicPath/base 配置（SPA 路由需要正确的 base path）、路由模式（history 模式需要 nginx/vercel 配置 fallback 到 index.html）、环境变量是否正确传入。
AI CI/CD 工具生态
除了用 Claude Code 生成配置和排查问题，还有一些专用工具在 CI 中自动运行：
| 工具 | 做什么 | 触发方式 |
|---|---|---|
| CodeRabbit | PR 自动 Review，逐行建议 | PR 创建时自动触发 |
| GitHub Copilot Autofix | 检测并自动修复安全漏洞 | CI 中自动运行 |
| Sentry Seer | 结合运行时数据预测 PR 中的错误 | PR 创建时自动触发 |
这些工具在 CI 中自动运行，不需要手动操作。Claude Code 做"你主动触发的深度分析"，这些工具做"CI 自动触发的快速扫描"——两者互补。
本节要点
- 两大支柱：容器化解决环境一致（Dockerfile → 镜像，任何机器可运行），矩阵化解决版本兼容（matrix 多 Node 版本/多系统并行验证）；容器化不是必选项，单应用裸机 + SSH 脚本部署也够用
- CI/CD 配置用提示词让 AI 生成：描述项目信息，AI 输出完整 YAML（pnpm/action-setup 在 setup-node 之前、cache: pnpm、--frozen-lockfile）
- Docker 实操要点：多阶段构建把开发依赖挡在最终镜像外；pnpm 10+ 构建脚本需 allowBuilds 批准且 pnpm-workspace.yaml 要在 install 前 COPY；国内加速用 npmmirror；AI 也要多轮迭代，不是一次配好
- CI 失败两种解法：手动
gh run view --log-failed喂日志；或把 GitHub token 给 AI 自动读日志修复 - 部署选型：海外/开源选 Vercel（Hobby 免费 100GB 带宽/月）、国内访问选 EdgeOne Pages（个人版免费）、私有部署选 Docker + 自有服务器——注意静态平台"先免后费"的额度玩法
至此第9章五个环节（初始化 → 版本控制 → 提交 → 质量防线 → CI/CD）全部打通。下一章开始，我们在这套工程骨架之上正式开发 ai-chat-ui 组件库。
↑